Remove allocator_api #762
Remove allocator_api #762
Conversation
lhecker
force-pushed
the
dev/lhecker/stable-allocator-api
branch
from
08690f0 to
ca6c7d8
Compare
| @@ -0,0 +1,5 @@ | |||
| mod string; | |||
There was a problem hiding this comment.
Add copyright header to new files
|
|
||
| /// See [`BVec::into_std_vec()`]. | ||
| pub fn into_std_string(self) -> String { | ||
| unsafe { String::from_utf8_unchecked(self.vec.into_std_vec()) } |
There was a problem hiding this comment.
Why not use from_utf8 and propagate the Utf8Error like the next function.
| fn grow(&mut self, alloc: &'a dyn Allocator, cap: usize, add: usize) { | ||
| debug_assert!(add > 0, "growing by zero makes no sense"); | ||
|
|
||
| #[cfg(debug_assertions)] |
There was a problem hiding this comment.
I believe this cfg is redundant with the debug_assert! macro.
There was a problem hiding this comment.
Oh I see. alloc is for debug purposes only and so this macro won't compile without the cfg. Please disregard this comment.
|
|
||
| /// Consume the string, returning a `&mut [T]` that lives as long as the borrowed memory. | ||
| #[inline] | ||
| pub fn leak(self) -> &'a mut [T] { |
There was a problem hiding this comment.
Although this is called leak, it does not seem to actually leak memory. It also does not seem to do anything useful compared to as_mut_slice. Maybe we don't need it?
| /// View as a shared slice. | ||
| #[inline] | ||
| pub fn as_slice(&self) -> &[T] { | ||
| self |
There was a problem hiding this comment.
This is a bit tricky/clever. I suppose it is using the Deref trait. I think it might be nice to be explicit and say Deref::deref() and DerefMut::deref_mut in as_mut_slice just to be clear. In those trait implementations, it is clear that this is using len to cap the length of the returned slice to the valid elements. Maybe it is helpful to mention that in the comments.
|
|
||
| /// Appends all elements from a slice. It's basically a `memcpy`-append. | ||
| #[allow(clippy::mut_from_ref)] | ||
| pub fn extend_from_slice(&mut self, alloc: &'a dyn Allocator, other: &[T]) { |
There was a problem hiding this comment.
Should we require T: Copy so that the ptr::copy_nonoverlapping will be valid?
There was a problem hiding this comment.
Lol never mind. I see the constraint on line 281 now. Pelase disregard this comment.
2 participants
Allocatoris not stable after a decade? Fine.We'll make our own
Allocator, with... uh..."high-stakes gamification and concierge-level support services"!
Closes #44